System and method for authentication via a proximate device

ABSTRACT

Techniques are provided to authenticate components in a system. Users may enter credentials into an input device and the credentials may be authenticated and/or securely transmitted to the components. The components may then provide the credentials to a server in the system. Strong authentication may thus be provided to the effect that credentials associated with specific users have been received from specific components in the system. The server may then enable the components to access selected services.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the benefit of U.S. Provisional PatentApplication No. 60/637,668, filed Dec. 20, 2004, the disclosure of whichis hereby incorporated by reference herein.

TECHNICAL FIELD

This application relates to data processing and, more specifically, to asystem and method of authenticating devices via at least one proximatedevice.

BACKGROUND

A variety of services may be accessed using computing devices such aspersonal computers and wireless handsets. For example, a user may accessdata stored on or applications running on the computing device. Inaddition, a user may connect to a data network to gain access to dataand applications on remote servers.

In some cases, access to a service may be limited to authorized users.For example, a service may provide access to sensitive data such asfinancial information or personal information. In addition, access to aservice may require payment of a fee.

A variety of techniques are known for securing access to services via acomputing device. For example, a user may be required to present someform of credential to a computing device that provides the service (the“service provider”). Here, the credential may indicate that a particularuser (or anyone who knows the credential) may access a given service. Insome applications a credential may take the form of a user name andpassword that was provided to the user and the service provider by asystem administrator. When the user accesses a service, the user maypresent the user name and password to the service provider. The serviceprovider then verifies that this credential is assigned to an authorizeduser of the requested service.

In a typical data network, access to the data network is limited todevices that have been properly installed on the network. As part ofthis installation, cryptographic techniques may be employed to ensurethat only authorized devices are connected to the network. In general,cryptographic techniques may include one or more of encryption,decryption, authentication, signing and verification.

For example, a network administrator may load one or more cryptographickeys (hereafter “key(s)”) into each device that is authorized to connectto the network. The network administrator also loads corresponding keysinto a network access device (e.g., a router) that is connected to, forexample, a wide area network (“WAN”). When the device attempts to accessthe network, the network access device verifies that a proper key hasbeen loaded into that device. Once verified, the network access deviceenables the requesting device access to the network.

In practice, the process of authorizing a user to use a service andinstalling devices on a network may be relatively cumbersome and timeconsuming. As described above, these operations tend to be relativelymanual in nature. However, distributed computing services are becomingincreasingly prevalent and affordable to access. For example, theproliferation of wireless computing networks and handheld devicesenables a user to use a variety of devices to access a variety ofdifferent networks that may exist throughout a city, etc. Accordingly, aneed exists for more efficient techniques for enabling a user to accesssecured services.

Moreover, conventional methods of entering or loading a credential or acryptographic key into a device may be compromised in somecircumstances. For example, when a user uses a computing device toaccess a secured service, the user may first need to enter thecredential into the computing device. Typically, this is accomplishedusing an input device such as a keyboard. The computing device may thenforward these credentials to a service provider that determines whetherthe user is authorized to use the requested service.

In the event the computing device has been comprised by a hacker or acomputer virus, an unauthorized person may gain access to thesecredentials. For example, a personal computer may incorporate a trustedcomputing module (“TPM”) to control access to certain secured services(e.g., access to an encrypted data file or a secured network). Here, theTPM may require a user to enter a password or other credential beforethe TPM allows the user to access these services. If the user uses akeyboard to enter this information, the password may be routed throughthe personal computer from the keyboard to the TPM via an insecure path.For example, the keyboard may connect to a USB port and a softwaredriver may be used to transfer the data from the USB bus to a TPM that,for example, is connected to a South Bridge of the personal computer.However, the hacker or virus may be able to access data that isforwarded and/or stored by the software driver. As a result, anunauthorized person may acquire the password and gain access to thesecured service.

Similarly, secret key information used in wireless devices may becompromised. For example, to enable secure communication between twoBluetooth devices, complementary keys may need to be loaded into eachdevice. In some applications, a key is transferred from one Bluetoothdevice to the other Bluetooth device via the Bluetooth network. However,an unauthorized person may be able to intercept the broadcast Bluetoothsignal containing the key. As a result an unauthorized person mayacquire the key and gain access to secured services.

Serious consequences may result when the secured services control andprovide access to sensitive information such as financial data orpersonal information. Accordingly, a need exists for more securetechniques for providing access to secured services.

SUMMARY

The invention relates to a system and method for authenticating a useror users to use one or more devices in a communication system. Forconvenience, an embodiment of a system constructed or a method practicedaccording to the invention may be referred to herein simply as an“embodiment.”

In one aspect the invention relates to authenticating a user to access aservice provided by or accessible via an access device (e.g., acomputing device). For example, the user may access data stored on theaccess device or on a remote computing device. The user also may accessapplications running on the access device or on remote servers. Inaddition the user may gain access to a data network via the accessdevice.

In one aspect of the invention, credentials for gaining access to theservice are provided to an input device that is proximate the accessdevice. Cryptographic techniques may then be used to authenticate and/orprotect the credentials.

In some embodiments, a secure communication mechanism may be establishedbetween the input device and the access device for transmission of thecredentials. For example, a user may initially provide the credentialsto the input device in a secure manner. In some embodiments this mayinclude entering the credentials into a security boundary in the inputdevice. A cryptographic processing component in the input device maythen cryptographically encrypt and/or sign the credentials within thesecurity boundary. Here, the authenticity of the signing/encrypting maybe verified to the access device by a published digital certificate. Theinput device then provides the signed/encrypted credentials to theaccess device.

The access device may then provide the credentials to a service providerto gain access to a service. In some embodiments, a secure communicationmechanism may be established between the access device and the serviceprovider. For example, a cryptographic processing component in theaccess device may cryptographically encrypt and/or sign the credentialswithin a security boundary. Here, the authenticity of thesigning/encrypting may be verified to third parties (e.g., a serviceprovider) by a published digital certificate. The access device thenprovides the signed/encrypted credentials to a service provider.

The service provider may validate that the credentials originate from aspecific access device. For example, a cryptographic processor in theservice provider may use the access device's public key to cause theaccess device to prove that it has the corresponding private key. Inaddition, since the service provider has access to a certificate for thepublic key, assurance may be provided that the access device has amechanism for protecting keys and that the private key of the accessdevice was not exposed outside of the security boundary. Consequently, ahigh level of assurance that the credentials came from a specific and/ortrusted access device that is currently being used by an authorized user(as authenticated by the cryptographic processing in the input device)may be provided to the service provider.

In some embodiments authentication may be used to verify that a user isin the proximity of the access device. For example, an authorized usermay be provided access to a service only when a wireless token assignedto the user is in the proximity of the input device which in turn is inrelative proximity to the access device through which access to thesecured service is obtained. In this way, a reasonable assumption may bemade that the authorized user is in fact using a specific access deviceto request the service.

In some embodiments an input sensor is implemented within a securityboundary on the input device. In this way, the credential may be passedvia the input sensor directly to the security boundary of the inputdevice then passed securely to the access device. As a result, thecredentials may be passed to the access device without being routed viasoftware messages or applications. As a result, the credentials may notbe intercepted by a hacker or computer virus that may have compromisedthe software executing on the access device.

In some embodiments the input device comprises a proximityauthentication system such an RFID system. For example, a user'scredentials may be stored on an RFID token and the input device mayinclude an RFID reader. In this case, the RFID reader reads thecredentials when the RFID token is proximate the input device.

In some embodiments the input device may comprise a biometric sensorsuch as a fingerprint reader. In this case, the credentials may includebiometric information (e.g., a scan of a fingerprint).

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects and advantages of the presentinvention will be more fully understood when considered with respect tothe following detailed description, appended claims and accompanyingdrawings, wherein:

FIG. 1 is a simplified block diagram of one embodiment of anauthentication system constructed in accordance with the invention;

FIG. 2 is a flow chart of one embodiment of authentication operationsthat may be performed in accordance with the invention;

FIG. 3 is a simplified block diagram of one embodiment of a userauthentication system constructed in accordance with the invention;

FIG. 4 is a flow chart of one embodiment of user authenticationoperations that may be performed in accordance with the invention;

FIG. 5 is a simplified block diagram of one embodiment of a userauthentication system constructed in accordance with the invention;

FIG. 6 is a flow chart of one embodiment of user authenticationoperations that may be performed in accordance with the invention;

FIG. 7 is a simplified block diagram of one embodiment of aproximity-based authentication system constructed in accordance with theinvention;

FIG. 8 is a flow chart of one embodiment of proximity-basedauthentication operations that may be performed in accordance with theinvention;

FIG. 9 is a simplified block diagram of one embodiment of an accessdevice constructed in accordance with the invention;

FIG. 10 is a simplified block diagram of one embodiment of a processingsystem constructed in accordance with the invention;

FIG. 11 is a simplified block diagram of one embodiment of a securitymodule constructed in accordance with the invention;

FIG. 12 is a flow chart of one embodiment of operations that may beperformed in accordance with the invention;

FIG. 13 is a simplified block diagram of one embodiment of a securitymodule constructed in accordance with the invention; and

FIG. 14 is a flow chart of one embodiment of operations that may beperformed in accordance with the invention.

In accordance with common practice the various features illustrated inthe drawings may not be drawn to scale. Accordingly, the dimensions ofthe various features may be arbitrarily expanded or reduced for clarity.In addition, some of the drawings may be simplified for clarity. Thus,the drawings may not depict all of the components of a given apparatusor method. Finally, like reference numerals denote like featuresthroughout the specification and figures.

DETAILED DESCRIPTION

The invention is described below, with reference to detailedillustrative embodiments. It will be apparent that the invention may beembodied in a wide variety of forms, some of which may be quitedifferent from those of the disclosed embodiments. Consequently, thespecific structural and functional details disclosed herein are merelyrepresentative and do not limit the scope of the invention.

In one aspect, the invention relates to systems and methods that providedevice and/or user level authentication. For example, various techniquesare described for authenticating that a user is using a device. Inaddition, various techniques are described for authenticating a deviceto a service such as enabling access to a data network.

In a conventional data network device level authentication may be usedto ensure that only authorized devices are allowed to connect to thenetwork. Here, cryptographic techniques may be employed to authenticatethat a device that is attempting to connect to the network is the deviceit purports to be and is authorized to use the network. For example, adevice typically connects to the network via an access point such as arouter. Compatible cryptographic keys are thus provided to the routerand to authorized devices to enable these devices to performcryptographic operations that provide the desired authentication. Insuch a network, a mechanism must be provided for securely distributingkeys to all devices that may connect to the network. Traditionally, thishas been accomplished by the user or a network administrator manuallyloading the keys into the devices (e.g., via a keyboard or a softwareprogram).

Such device level authentication may have a number of drawbacks. Forexample, there may not be any verification as to which user is using thedevice. Moreover, when multiple users use the same device, there may notbe an efficient mechanism to determine which verification information(e.g., cryptographic certificate) should be used to authenticate to thesystem.

FIG. 1 illustrates one embodiment of a system 100 constructed inaccordance with the invention where one or more users (not shown) mayuse one or more access devices 102 and 104 to access services (e.g.,connect to a data network) via an access server 106. For example, toaccess a service a user presents authentication information (e.g.,credentials such as a password) to an input device 108. For conveniencethe term “credential(s)” may be used to refer generally to any type ofinformation that a user may present for authentication purposes.

The input device 108 may include a security processing component (e.g.,a security module 110, a processor with code for cryptographicoperations, etc.) that provides cryptographic processing and mayincorporate other security mechanisms. For example, the security module110 may include one or more cryptographic processors that performcryptographic operations such as encryption, decryption, authentication,verification and signing. Using the security module 110, the inputdevice 108 may authenticate the credentials received from the user. Theinput device 108 may then securely send the credentials via an interface(e.g., an RF interface 124) to an access device 102 or 104 via signals118 through a medium (e.g., a wireless medium).

The access device 102 or 104 includes an interface (e.g., RF interface126 or 128) for receiving the signals 118. The access device 102 or 104includes some form of processing (e.g., access processor 130 or 132) foraccessing a service. For example, in some embodiments the accessprocessor may comprise a processor for a cell phone or some other formof wireless device.

The access device 102 or 104 also may include a security processingcomponent (e.g., security module 112 or 114) that provides cryptographicprocessing and may incorporate other security mechanisms. For example, asecurity module may include one or more cryptographic processors thatperform cryptographic operations such as encryption, decryption,authentication, verification and signing. Using the security module, anaccess device 102 or 104 may authenticate the credentials received fromthe input device 108. The access device may then securely send thecredentials via an interface (e.g., interface 134 or 136) to the accessserver 106 via signals 120 over a medium (e.g., a wireless medium).

The access server 106 includes an interface (e.g., interface 138) forreceiving the signals 120. The access server includes some form ofprocessing 140 for providing access to a service. For example, in someembodiments the access processor may comprise a network server for awired and/or wireless network.

The access server 106 also may include a security processing component(e.g., security module 116, a key manager, etc.) that providescryptographic processing and may incorporate other security mechanisms.Here, the security module 116 may process the received credentials to,for example, authenticate and/or decrypt the credentials. The abovearchitecture may thus provide relatively strong authentication to theaccess server 106 that the credentials have been presented to a trustedinput device 108 that is associated with a trusted access device 102 or104. As a result, the access server 106 may enable the access device 102or 104 to access the requested service.

Selected operations of the system 100 will be explained in more detailin conjunction with the flowchart of FIG. 2. As represented by block202, one or more keys may be generated to enable the input device 108 tosecurely communicate with an access device (e.g., access device 102). Insome embodiments, this is accomplished through the use of asymmetrickeys.

For example, a unique asymmetric identity key may be provided for theinput device 108 during manufacture or at some later time. The privatekey portion of this asymmetric key may be stored within a securityboundary (e.g., the security module 110) in the input device 108. Forexample, a processor (e.g., a multi-purpose processor or a cryptographicprocessor) may generate the key within this security boundary and theprivate portion of the key may never be allowed to appear outside of thesecurity boundary in the clear (i.e., unencrypted). Additional detailsof a security boundary are provided below.

The public portion of the key may then be published with a digitalcertificate. For example, the manufacturer of the input device maypublish the public key and the certificate on a publicly accessibleserver. The certificate may serve to verify that the public key isauthentic, that the private key has not been disclosed outside thesecurity boundary and that the input device that holds the private keyprovides a mechanism to securely receive, use and maintain keys. Thus,the certificate serves to strongly verify the authenticity of anyinformation provided by an input device that has the correspondingprivate key.

In some embodiments, the input device and the access device may use theasymmetric key to negotiate one or more other keys that may be used forcryptographic processing. For example, these other keys may be used toencrypt, decrypt, sign, etc., information send between these components.In this way, an authenticated and/or secure channel may be establishedbetween the input device and the access device. That is, each componentwill have one or more keys that enable it to encrypt, decrypt orauthenticate information that it sends to or receives from the othercomponent. In this way, sensitive information (e.g., credentials orkeys) may be securely sent over a link 118 (e.g., a wireless link suchas Bluetooth, etc.) that may not otherwise be secure.

Referring now to block 204, keys also may be generated for the securitymodule in the access device during manufacture or at some later time.Thus, a unique asymmetric identity key may be provided for the accessdevice 102. The private key portion of this asymmetric key may be storedwithin a security boundary (e.g., the security module 112) in the accessdevice 102. The public portion of the key may then be published with adigital certificate that may serve to verify that the public key isauthentic, that the private key has not been disclosed outside thesecurity boundary and that the access device that holds the private keyprovides a mechanism to securely receive, use and maintain keys. Thus,the certificate serves to strongly verify the trustworthiness of theaccess device. This asymmetric key pair may then be used to establish anauthenticated and/or secure channel between the access device and theaccess server or some other device.

Referring now to block 206, once the devices are installed in the field,the devices and the access server may establish secure channels overmedia that may otherwise be insecure. In some embodiments this mayinvolve performing asymmetric key exchange operations.

At block 208, to enable the access server to recognize the credentialsassigned to a given user, the credentials are enrolled (e.g., enteredinto) the access server. This may be accomplished, for example, using acredential enrollment mechanism. Additional details of variouscredential enrollment mechanisms are discussed below.

The credential enrollment mechanism provides the credential informationto the security module 116 which may then generate one or more keysassociated with that credential. These keys may comprise, for example,SSL or IPsec keys/security associations that may enable the user to logonto a security network.

Referring to block 210, when a user wishes to access a service via theaccess device 102, the user presents his or her credentials to a datainput component 122 on the input device 108. The data input componentmay comprise a keypad, an RFID reader, a sensor, etc.

In some embodiments the input device 108 is a biometric sensor. Forexample, the sensor may comprise a fingerprint reader. Alternatively,the sensor may comprise a retina/iris scanner, an audio input device(e.g., a microphone) for speech recognition, a camera sensor (e.g., aCCD device) for, e.g., facial feature recognition or a DNA typingdevice. In addition, appropriate processing may be provided on thesensor integrated circuit to facilitate retrieval and analysis of thisinformation.

In some embodiments credentials may be provided to the input device viaa direct path into the security boundary of the input device. Forexample, credentials may be directly entered into a device locatedwithin a security boundary. This may be accomplished, for example, usinga keyboard, an RFID reader, a biometric sensor, etc., that is physicallyattached to a component within the security boundary. Additional detailsof these types of components are discussed below.

Referring to block 212, the input device 108 sends the credentials tothe access device 102 via the authenticated and/or secure channeldiscussed above. For example, a cryptographic processor in the inputdevice may use a key obtained from the negotiation with the accessdevice 102 discussed above to sign and/or encrypt the credentials.Typically, the cryptographic processor signs the credentials using sucha key or the private key of the input device.

Referring to block 214, the access device 102 processes the credentials,as necessary, and sends the credentials to the access server 106 via theauthenticated and/or secure channel 120 discussed above. For example, acryptographic processor in the access device 102 may use a key obtainedfrom the negotiation with the access server 106 discussed above toencrypt the credentials. Typically, the cryptographic processor signsthe credentials using such a key or the private key of the access device102.

At block 216, cryptographic processor(s) in the access server 106process the encrypted/signed credentials. Through this cryptographicprocess, the access server obtains strong authentication that thecredentials are from a user that is using a specific access device 102.Moreover, assurances may be made via the certificate that the inputdevice (e.g., keyboard, sensor, RFID components, etc.) through which auser inputs credentials is proximate to that access device.

The access server 106 then checks the credential database to verify thatthe credentials are associated with an authorized user. If so, theaccess server 106 generates or retrieves the key (e.g., key A) thatcorresponds to that credential or otherwise enables access to arequested service. The access server may then, for example, send the keyto the access device 102 (block 218). Typically, the cryptographicprocessor 124 will encrypt the key to protect it during transmission.Here, the cryptographic processor may use a negotiated key or the publickey associated with the private key to encrypt key A.

Once the access device 102 receives encrypted key A, the cryptographicprocessor decrypts key A and uses it to, for example, establish aconnection with a network (block 220).

Referring now to FIG. 3 additional details of the authentication processwill be discussed. FIG. 3 illustrates one embodiment of a system 300constructed in accordance with the invention where one or more users(not shown) may use one or more access devices 302 and 304 to accessservices 330 (e.g., connect to a data network) via an access server 306.For example, to access a service a user presents authenticationinformation (e.g., credentials 308 such as a password) to the accessdevice 302 via a proximate input device (not shown). For convenience theterm “credential(s)” may be used to refer generally to any type ofinformation that a user may present for authentication purposes.

The access device 302 may include a security module that providescryptographic processing and may incorporate other security mechanisms.For example, a security module may include one or more cryptographicprocessors 328 that perform cryptographic operations such as encryption,decryption, authentication, verification and signing. Using the securitymodule, the access device 302 may authenticate the credentials receivedfrom the input device and securely send the credentials to a key manager310 in the access server 306.

The key manager 310 provides a secure environment for generating,assigning and maintaining keys that are used in the system. The keymanager includes one or more cryptographic processors 324 for securelyperforming cryptographic operations including encryption, decryption,authentication, etc. The key manager also includes a secure data memory322 for storing keys 326 in a manner that prevents the keys from beingaccessed by unauthorized persons or methods.

To provide secure processing and key storage a security boundary isassociated with and enforced by the key manager. This security boundarymay be established, for example, using hardware and/or cryptographictechniques.

Hardware techniques for providing a security boundary may include, forexample, placing components within a single integrated circuit. Inaddition, one or more integrated circuits may be protected by a physicalstructure using tamper evident and/or tamper resistant techniques suchas epoxy encapsulation.

Encryption techniques for establishing a security boundary may include,for example, encrypting any sensitive information before it leaves thekey manager. For this purpose, the key manager may use one or more ofthe cryptographic processors 324 and store the associatedencryption/decryption keys 326 in an internal secure data memory 322.

To maintain the security of the system 300, any keys distributed by thekey manager to other components in the system should be adequatelyprotected. For example, provisions may be made to ensure that keys areonly delivered to authorized devices. In addition, provisions may bemade to protect the keys during distribution and within the recipientdevices.

In some embodiments the access device 302 includes one or morecryptographic processors 328 and keys (e.g., key 314) to authenticateinformation that is sent from the access device 302 to the access server306, to facilitate secure transmission of keys to the access device 302,and to protect the keys used by the access device 302.

For example, using digital certificates and other cryptographicprocesses the access device 302 may provide strong authentication to theaccess server 306 that the credentials it sends to the access server 306are from a user that is using that specific access device. In addition,these processes may be used to verify that the access device 302provides a high level of protection for key material.

Once this authentication is provided to the access server 306, the keymanager 310 may safely distribute keys to the access device 302 tofacilitate access to the desired service. For example, the key managermay distribute keys to the access device to enable the access device toconnect to a data network.

The embodiment of FIG. 3 provides an efficient mechanism that enables auser to, for example, use a variety of access devices to gain access toa network. Here, the user initially authenticates himself or herself toeach device. The access server then automatically builds the network bydistributing the necessary keys to each device. As described herein thisprocess may be accomplished with a high level of security. Moreover,since the access server provides the appropriate keys to each device,the key material does not need to be given to the user. In addition, theuser may not be required to, for example, provide a digital certificateto each access device he or she uses in the network.

Selected operations of the system 300 will be explained in more detailin conjunction with the flowchart of FIG. 4. As represented by block402, one or more keys may be generated to enable the access device tosecurely communicate with the access server. In some embodiments, thisis accomplished through the use of asymmetric keys.

For example, a unique asymmetric identity key 314 may be provided foreach access device. The private key portion of this asymmetric key maybe stored within a security boundary (represented by dashed line 312) inthe access device. For example, a cryptographic processor 328 maygenerate the key within this security boundary and the private portionof the key may never be allowed to appear outside of the securityboundary 312 in the clear (i.e., unencrypted). Additional details of asecurity boundary are provided below.

The public portion of the key may then be published with a digitalcertificate. For example, the manufacturer of the access device maypublish the public key and the certificate on a publicly accessibleserver. The certificate serves to verify that the public key isauthentic, that the private key has not been disclosed outside thesecurity boundary and that the access device that holds the private keyprovides a mechanism to securely receive, use and maintain keys. Thus,the certificate serves to strongly verify the authenticity of anyinformation provided by an access device that has the correspondingprivate key.

In some embodiments, the access device and the access server may use theasymmetric key to negotiate one or more other keys that may be used forcryptographic processing. For example, these other keys may be used toencrypt, decrypt, sign, etc., information send between these components.In this way, a secure channel (represented by dashed lines 316) may beestablished between the access device and the access server. That is,each component will have one or more keys that enable it to decryptencrypted information that it received from the other component. In thisway, sensitive information (e.g., keys) may be securely sent over a link318 that may not otherwise be secure.

Referring now to block 404, to enable the access server to recognize thecredentials assigned to a given user, the credentials are enrolled(e.g., entered into) the access server. This may be accomplished, forexample, using a credential enrollment mechanism 320. In someembodiments the credential enrollment mechanism may comprise a keyboardand monitor console for the server. In some embodiments the credentialenrollment mechanism 320 may be inside a security boundary associatedwith and enforced by the key manager 310. For example, the credentialenrollment mechanism 320 may comprise a keyboard that is physicallyattached to the key manager, an RFID reader, a biometric sensor, etc.Additional details of these types of components are discussed below.

The credential enrollment mechanism 320 provides the credentialinformation to the key manager 310 which may then generate one or morekeys associated with that credential. These keys may comprise, forexample, SSL or IPsec keys/security associations that may enable theuser to log onto a security network. The key manager may then maintain adatabase that associates each authorized user's credential (e.g.,credential A) with key(s) and certificate(s) (e.g., key A) that may begenerated for that user.

The credentials and the associated key(s) may be stored in a secure datamemory 322. In some embodiments the data memory 322 may be protectedwithin a physical security boundary of the key manager 310. For example,the database 322 may be located within a secure enclosure and/or withinthe same integrated circuit as the key manager. In some embodiments thedata memory 322 may be located external to the key manager. In thiscase, however, the key manager may encrypt the keys before they arestored in the data memory.

Referring to block 406, when a user wishes to access a service via theaccess device 302, the user presents his or her credentials 308 to theaccess device. As discussed above, the credentials 308 are provided tothe access device via a proximate input device.

In some embodiments credentials may be provided from the input device tothe access device via a direct path into the security boundary of theaccess device. For example, in the access device 304 credentials 332 maybe directly entered (as represented by dashed line 334) into a devicelocated within a security boundary 336. This may be accomplished, forexample, using a wireless interface that is physically attached to acomponent within the security boundary.

Referring to block 408, the access device 302 sends the credentials 308to the access server 306 via the secure channel 316 discussed above. Forexample, a cryptographic processor 328 may use a key obtained from thenegotiation with the access server 306 discussed above to encrypt thecredentials. Typically, the cryptographic processor(s) 328 sign thecredentials using such a key or the private key 314.

At block 410, cryptographic processor(s) 324 in the access server 306process the encrypted/signed credentials. Through this cryptographicprocess, the access server obtains strong authentication that thecredentials are from a user that is using a specific access device 302.Moreover, assurances may be made via the certificate that an inputdevice (e.g., keyboard, sensor, RFID components, etc.) through which auser inputs credentials is proximate to that access device.

The access server 306 then checks the credential database to verify thatthe credentials are associated with an authorized user. For example, theaccess server may determine whether the credential matches a credential(e.g., credential A) stored in the data memory 322.

If so, the access server 306 generates or retrieves the key (e.g., keyA) that corresponds to that credential. The access server then sends thekey to the access device 302 (block 412). Typically, the cryptographicprocessor 324 will encrypt the key to protect it during transmission.Here, the cryptographic processor may use a negotiated key or the publickey associated with the private key 314 to encrypt key A.

Once the access device 302 receives encrypted key A, the cryptographicprocessor 328 decrypts the key and stores decrypted key A 340 within thesecurity boundary 312. Here, the cryptographic processor 328 may use anegotiated key or the private key 314 to decrypt key A. The accessdevice 302 may then use key A 340 to, for example, establish aconnection with a network (block 414).

If desired, the user may then use another access device (e.g., accessdevice 304) to access the network. Again, the user presents his or hercredentials (e.g., the same credentials referred to above) to accessdevice 3.04 via the input device (not shown). Cryptographic processor(s)342 may then encrypt/sign the credentials and send them to the accessserver via a secure channel 346 over a link 348 that may not otherwisebe secure. Again, an asymmetric identity key 344 may be used toestablish the secure channel 346, form the basis of a digitalcertificate, sign credentials, etc. The access server 306 then verifiesthe credentials. Here, since the access server has received the samecredentials it may assume that the same user has authenticated to theaccess device 304. Accordingly, the access server sends the same key(e.g., key A) to the access device 304 via the secure channel 346,thereby binding these access devices together. The cryptographicprocessor 342 decrypts encrypted key A and stores decrypted key A 350within the security boundary. Access device 304 may then use key A toconnect to a network or access another service.

In addition, more than one set of credentials may be presented to agiven access device to access a network. For example, multiple usersthat are assigned different credentials may share an access device. Inaddition, the same user may have different credentials that provideaccess to different services such as personal services or employerprovided services. Accordingly, another set of credentials may be storedin the access server database and associated with a unique key (e.g.,key B). When these other credentials are presented to the access device304, the key B will be provided to the access device 304 using thesecure techniques discussed above. Accordingly, access device may usethe key B 350 to establish a separate, cryptographically secureconnection to a network.

These aspects of the invention will be described in more detail inconjunction with FIGS. 5 and 6. FIG. 5 is a simplified diagram of oneembodiment of a network system that may support a variety ofcommunication and data processing devices.

In FIG. 5 access devices connect to a wide area network (“WAN”) 502 suchas the Internet via an access point (e.g., a router) 504. Here, theaccess point may serve as the access server discussed herein.Alternatively, the access point 504 may connect to an access server (notshown) such that the credentials and keys pass through the access pointas they are sent between the access server and the access devices. Ineither case, credentials for any users that are authorized to access thesystem may be enrolled with the access server.

The access point 504 may provide connectivity for wired or wirelessdevices. For example, a network printer 512 may be connected to theaccess point by a wired connection as represented by line 506. Avoice-over-Internet-Protocol (“VoIP”) phone 514 also may connect to theaccess point via a wired connection as represented by line 508.

Other devices may connect to the access point via radio frequency (“RF”)signals as represented, for example, by the curved lines 510. Here, theaccess point 504 may support wireless standards such as Bluetooth,802.11, GSM, etc.

Examples of access devices include a VoIP phone 514 that supports theBluetooth protocol; a laptop computer 516 that supports 802.11 and/orBluetooth; a personal digital assistant (“PDA”) 518 that supports 802.11and/or Bluetooth and may include a cellular telephone that supports, forexample GSM; a personal entertainment device 520; a phone 522 thatsupports GSM and/or 802.11 and that communicates with peripherals suchas a wireless headset 524 via Bluetooth; and a personal computer 526that supports an 802.11 wireless connection and that communicates withwireless peripherals such as a Bluetooth-enabled keyboard 528 and mouse530.

As discussed herein, each of the devices 512-530 may include a securitymodule (not shown) that enables the device to securely and efficientlyreceive any keys necessary to connect to the data network 502 and/or toother devices. In the latter case, for example, keys may be securelydistributed between devices to enable a peripheral (e.g., keyboard 528)to securely communicate with a base device (e.g., computer 526).Accordingly, users may connect any of these devices to the network orother devices by simply providing their credentials to one or more inputdevices 536 which then route the credentials to the device(s) asdiscussed herein. For example, an input device 536 may communicate witha device 512-530 to provide a credential to a device 512-530. In thecase of the peripherals (e.g., keyboard 528), the credentials may bepassed through the base device (e.g., computer 526), then routed to theaccess server 504.

Additional details of the authentication components and processes thatmay be incorporated into these devices are described herein. Forexample, several embodiments for providing credentials to an accessdevice or an access server are discussed below in conjunction with FIGS.7-10. In addition, several embodiments of security modules are discussedbelow in conjunction with FIGS. 11-14.

Referring to FIG. 6, a simplified flowchart is illustrated relating tooperations that may be performed in a network system (e.g., as shown inFIG. 5). For example, such a system may include multiple access devicesand support multiple users and multiple levels of credentials. Ingeneral, these operations may be performed as discussed herein, forexample, in conjunction with FIGS. 3 and 4. For convenience, not all ofthe operations involved in the process are illustrated in FIG. 6 ordiscussed below.

As represented by block 602, a credential for a user (referred to forconvenience as “user A”) is enrolled with the access server. At block604, user A presents his or her credential to an input device that thensends the credential to an access device (referred to for convenience as“access device 1”). The access device 1 sends the credential to theaccess server and, after the access server verifies that the credentialhas been enrolled, the access server sends the associated key(s) to theaccess device 1 (block 606). Access device 1 may then use the key(s)associated with user A to connect to the network (block 608).

Blocks 610-614 illustrate that a network may be automatically built as auser provides his or her credentials to multiple access devices in thesystem. As represented by block 610, user A may provide his or hercredential to another access device (referred to for convenience as“access device 2”) via the input device. The access device 2 sends thecredential to the access server and, after the access server verifiesthat the credential has been enrolled, the access server sends theassociated key(s) to the access device 2 (block 612). Access device 2may then use the key(s) associated with user A to connect to the network(block 614).

Blocks 616-622 illustrate that a given device may be used by severalusers to access the network. Here, each of the users may be assigneddifferent credentials. As represented by block 616, a credential foranother user (referred to for convenience as “user B”) may be enrolledwith the access server. At block 618, user B also may provide his or hercredential to the access device 1 via the input device. The accessdevice 1 sends the credential to the access server and, after the accessserver verifies that the credential has been enrolled, the access serversends the associated key(s) to the access device 1 (block 620). Accessdevice 1 may then use the key(s) associated with user B to establish anentirely separate and cryptographically secure connection with thenetwork (block 622).

In practice, the separate set of credentials identified above as beingassociated with user B may be a second set of credentials assigned to agiven user (e.g., user A). For example, a user may have one set ofcredentials assigned for one network (e.g., a home network) and anotherset of credentials assigned for access to another network. Referring toFIG. 5, the devices 514 and 516 may be used to connect to an enterpriseLAN at the user's office. In this case, the second set of credentialsmay be provided to the office network 534 via the WAN 502 and otherrouting mechanisms 532. Once the appropriate keys are exchanged, anenterprise virtual private network (“VPN”) or other form of connectionmay be established between the access device and the office network 534.Again, this network may be entirely separate and cryptographicallysecured from any other network connections for that user or any otheruser of the system.

Blocks 624-628 illustrate that the network may be continued to beautomatically built as other users provide his or her credentials tomultiple access devices in the system. As represented by block 624, userB may provide his or her credential to another access device (referredto for convenience as “access device 3”). The access device 3 sends thecredential to the access server and, after the access server verifiesthat the credential has been enrolled, the access server sendsassociated key(s) to the access device 3 (block 626). Access device 3may then use the key(s) associated with user B to connect to the network(block 628).

The system described above may provide several advantages as compared toconventional systems. Traditional networks may only provide device levelauthentication that is achieved by manually configuring the head end andall devices that may connect to the network. For example, the router maybe configured by an administrator physically connected to a LAN port ofthe router. Here, the administrator may enter in the keys for the routerand identify each of the devices that may connect to the router. Inaddition, the administrator may manually configure each device in thenetwork with the necessary key to enable the device to connect to thatspecific router.

In contrast, a network constructed using the teachings described hereinmay be automatically built by binding components (e.g., access devices)together as a user authenticates himself or herself to these components.This is facilitated, for example, by the ability to securelyauthenticate at the system level. For example, the proximity of the usermay be verified as well as the ability of a security module to protectkeys (e.g., using appropriate hardware).

A variety of secure techniques may be used to authenticate a user to adevice. For example, a credential may be provided via a directconnection into an input device, credentials may be injected into asecurity boundary of a device via RFID signals or a sensor may bephysically located within a security boundary of a device.

Here, the network may be built using digital certificates based onpublic/private keys pairs. This process may be initiated by using aprivate key that is protected on each component and may provide a secureenvironment where the components may dynamically change the keys.

In addition, each user does not need access to the keys that identifythat user since the user does not need to pre-configure each device withthe appropriate key. Instead the user may only present information suchas a credential to obtain access to the network via a given device.

Moreover, a system may be configured to provide multiple networks. Eachof these networks may include a given set of components that are definedfor different users and/or for different permission levels for a givenuser. These networks may be secured from one another by usingcryptographic techniques to authenticate access to each network andsecure the data flowing though each network.

Referring now to FIGS. 7-10, several embodiments of mechanisms forproviding credentials to a device will be discussed. In general, thefollowing description describes providing credentials to an accessdevice. However, these mechanisms also may be used to providecredentials to an access server or some other component in a system.

FIG. 7 illustrates one embodiment of a system 700 where selectedservices may be provided to a user via a computing device when awireless token assigned to a user is proximate to the input device. Aninput device 716 includes components that may be used to determinewhether a wireless token (e.g., an RFID token) 742 assigned to a user orusers is proximate to the input device 716. For example, a wirelessproximity reader (e.g., an RFID reader 728) may be configured to receivesignals 744 (e.g., RF signals) from the wireless proximity token 742.The signals 744 may include information that uniquely identifies thewireless proximity token 742. For example, this information may includeone or more credentials (e.g., a password) that may be used to access asecured service through an access server 704.

The determination of proximity between the token 742 and the reader 728may be established using a variety of mechanisms depending on theapplication. In some embodiments, the token will not generate signalsuntil it is within a given distance of the reader. This may beaccomplished, for example, by using a relatively passive token thatintercepts signals transmitted by the reader and transmits signals inresponse to the received signals. Different distances between the token742 and the reader 728 may be defined as indicative of proximitydepending on the requirements of the application and, in some cases,characteristics of the operating environment.

RF interfaces (e.g., Bluetooth interfaces) 736 and 706 and associatedantennas 734 and 732 may then be used to send the credentials from theinput device 716 to the access device 702 via RF signals 730. The RFinterfaces also may be used for other communications between the inputdevice 716 and the access device 702.

An access device 702 such as a computer may request access to a servicefrom the access server 704 by sending a request over a communicationlink 726. Depending upon the particular application, the communicationlink 726 may comprise, for example, electric wires, optical cables orair. Thus, the access device 702 may support wired or wirelesscommunications with the access server 704.

Typically, access to the service will be initiated by the user'sinteraction with the access device 702. For example, the user may use akeyboard or pointing device (e.g., a computer mouse) to access theservice. In conjunction with this the user may be required to input apassword and/or provide a biometric (e.g., a fingerprint) to a biometricsensor to verify the authenticity of the user. In this way, access to aservice may be withheld until the user provides adequate credentialsincluding, for example, what the user knows (e.g., a password), what theuser possesses (e.g., a token) and who the user is (e.g., a physical orbiometric characteristic).

The input device 716 and the access device 702 may incorporate securitymechanisms to ensure that the credentials provided by a user may besecured when the credentials are maintained within and sent from thesedevices. For example, the input device may provide a security boundarywithin which any sensitive information (e.g., credentials received fromthe token and keys received from the access device) may be used andmaintained in a secure manner. In addition, the access device mayprovide a security boundary to protect any sensitive information (e.g.,keys and credentials)

To this end, these devices may include security modules 708 and 746 thatprovide cryptographic processing to, for example, sign and/or encryptthe credentials. In some embodiments information may only pass betweenthe reader 728 and the security module 746 via a connection within acommon integrated circuit. Thus, the input device may be configured sothat the credentials never leave the integrated circuit in the clear.

In addition, the access device 702 may be in secure communication withthe access server 704. For example, a cryptographically securedcommunication channel 718 may be established between the security module708 and the access server 704. In this case, the security module 708 mayprocess (e.g., encrypt/sign) the credentials before sending them to theaccess server 704. Accordingly, the security modules may provide strongauthentication that the credentials are from a specific token 742 thatis proximate that particular input device 716 that, in turn, isrelatively proximate a specific access device 702.

After the access server 704 has received authenticated credentials fromthe access device 702, the access server may provide access to therequested service. As used herein the term service may include, forexample, access to data and/or a data processing service. Thus, aservice may enable an access device to, for example, read or write datain a data memory, access encrypted data, use cryptographic keys, gainaccess to cryptographic material such as security associations and keys,access a web page, access a data network or access a processingapplication.

As used herein the term data may include any information that may beaccessed by a computing device including, for example, data files,passwords and cryptographic security associations including keys.

As used herein the term access may include, for example, acquiring,using, invoking, etc. Thus, data may be accessed by providing a copy ofthe data to the access device. Data also may be accessed by enabling theaccess device to manipulate or use the data. As an example of thelatter, once a user has been authorized to access a service a trustedplatform module may use keys to perform operations for the user. For adata network, access may include, for example, sending and/or receivingdata over the network. For a processing application access may include,for example, invoking, interacting with or using the application orloading the application onto the access device.

An access server may comprise hardware and/or software that facilitateproviding a service. For example, an access server may consist of aprocessing system that processes requests for service, verifies whetherthe requester is authorized to access the service and provides orfacilitates the requested access.

In practice, an access server may be located local or remote withrespect to the entity requesting service (e.g., access device 702). Forexample, a local trusted platform module may control access to passwordsin a computing system. In addition, a remote wireless access point maycontrol a computing system's access to a data network connected to theaccess point.

An access device may comprise hardware and/or software that facilitateaccess to a service. For example, an access device may comprise acomputing system such as, without limitation, a personal computer, aserver, a cellular phone, a personal data assistant (“PDA”), etc.

For convenience, FIG. 7 only depicts one token, input device, accessdevice and access server. It should be understood, however, that asystem may include any number of these components. For example, a usermay use a token to access one or more services via one or more accessdevices. Thus, an access device may access services from multiple accessservers. Also, multiple access devices may access the services providedby a given access server.

Authorization to access a service may depend on the specific token andaccess device being used. For example, a user may be assigned one tokento access certain services through certain access devices. In addition,the user may be assigned another token to access other services throughthe same or other access devices. Also, multiple sets of information(e.g., credentials) may be included on a single token to enable a userto access different services or to enable multiple users to share atoken.

A wireless proximity reader and token may be implemented using one ormore of a wide variety of wireless proximity techniques. For example,the proximity reader and the token may support, without limitation, oneor more of RFID, ISO 14443 and ISO 15693.

Tokens may be implemented in various physical forms depending upon theneeds of the respective applications. For example, a token may be in aform that is easy to carry, similar to a plastic credit card, a “smartcard” or a building access card. Also, a token may take the form of atag or a label that may be attached to another article.

Examples of tokens may include, without limitation, smart cards, creditcards, dongles, badges, biometric devices such as fingerprint readers,mobile devices such as cellular telephones, PDAs, etc. In someembodiments, the token includes circuitry used in a typical smart card.For example, the token may store an encrypted password that may be sentto an authentication system.

Referring now to FIG. 8 additional details of operations andconfigurations in a proximity-based authentication system will bedescribed. As represented by block 802, a security boundary is providedwithin the input device 716 and the access device 702 to, for example,secure the process of gaining access to a service, including securingthe authentication process and information used during theauthentication process. This security boundary may be established, forexample, using hardware and/or cryptographic techniques.

Hardware techniques for providing a security boundary may include, forexample, placing components within a single integrated circuit. As shownin FIG. 7 an RF interface 706, a security module 708 and otherprocessing components 710 may be incorporated into a single integratedcircuit 712. Thus, any processes performed or information used or storedwithin the integrated circuit 712 may not be compromised absent physicalaccess to the integrated circuit 712 and the use of an invasivetechnique for analyzing the internal operations and data of theintegrated circuit 712. For many applications, this form of hardwaresecurity boundary may provide an acceptably high level of security.

Other means may be used to provide a security boundary. For example, oneor more integrated circuits (e.g., integrated circuit 712) may beprotected by a physical structure using known techniques (e.g., epoxyencapsulation). Also, the access device 702 and/or its internalcomponents may be tamper resistant and/or tamper evident.

Cryptographic techniques for providing a security boundary may includeencrypting any important information that is sent to or from theintegrated circuit via non-secure paths in the system. For example,security associations and keys may only appear in the clear within theintegrated circuit 712. In the event keys need to be sent out of theintegrated circuit 712 (e.g., to be stored in a data memory 714), thekeys may first be encrypted.

Similarly, any important information that is sent between the integratedcircuit 712 and the access server 704 may be encrypted. For example,information (e.g., credentials) received from the RFID token 742 may beencrypted before being sent over the link 726.

In FIG. 7 one cryptographic security boundary is represented by thedashed line 718. The line 718 represents, in part, that encryptedinformation may be sent between the security module 708, the processingcomponent 710 and the data memory 714. Thus, the information may be sentsecurely even though the mechanism through which this information issent (e.g., a data bus 720) may not be secure.

Encrypted information also may be sent between the integrated circuit712 and a cryptographic processor 722 in a key manager 724 in the accessserver 704 via the communication link 726. In this case, thecryptographic processors may perform key exchange and encryption,decryption and/or authentication operations as necessary to send andreceive the encrypted information and provide the information in theclear for internal processing.

In general, the form of protection provided within the system may dependon the requirements of a given application. For example, specificationssuch as FIPS-140-2 define various levels of security that may beimplemented within a system

The security boundary provided by the integrated circuit 712 and thecryptographic boundary 718 may be used to provide a secure mechanism forauthenticating a user to access a service. For example, credentialsreceived from the RFID token 742 may be provided directly into anintegrated circuit on the input device 716 via RF signals 744.

Once the information is in the integrated circuit on the input device716 it may be protected by the physical boundary of the integratedcircuit and by a cryptographic boundary (not shown). For example,provisions may be made to ensure that the information does not appear inthe clear outside of the integrated circuit. The information may then besecurely sent to the access device 702 via what may otherwise be aninsecure link 730.

Credentials received from the input device 716 may be provided directlyinto the integrated circuit 712 via RF signals 730. Once the informationis in the integrated circuit it may be protected by the physicalboundary of the integrated circuit and by the cryptographic boundary718. Thus even if rogue software in the system were to gain access tothe information outside of the chip 712, the software would not be ableto decrypt it without appropriate key information. However, the keyinformation also may be protected within the integrated circuit 712 andthe cryptographic boundary 718. That is, the key information may notappear in the clear outside of the security boundary. As a result, thecredentials may be securely routed to the access server 704.

Moreover, via this secured mechanism, the access device 702 may reliablyauthenticate to the access server 704 that a specific RFID token 742 isproximate the input device 716. First, as discussed above, thecredentials may be received in a secure manner. Second, the effective“decision” as to whether the token 742 is adjacent may be made within asecurity boundary. The security module 708 may then cryptographicallysign this information using a secure protocol set up between it and thecryptographic processors 722 of the key manager 724. Via this signaturethe access server 704 may be assured that a given message came from aspecific processing system (e.g., access device 702) and that themessage has not been compromised. Accordingly, proximity of the token742 to the input device 716 may be used as a reliable method ofauthorizing access to a secured service provided by the serviceprovider.

Referring again to FIG. 8, an example of operations that may be used toaccess a service will be described. As represented by block 804, whenthe RFID token 742 is within an appropriate range of the input device716, the RFID reader 728 will receive an RFID signal 744 from the RFIDtoken 742. As discussed above, the RFID signal 744 may be received bythe input device 716 within a security boundary.

As represented by block 806, the system 700 may be configured so thatany information contained within the broadcast RFID signal may beextracted only within a security boundary. For example, as shown in FIG.7, the RFID reader 728 that extracts the credentials from the RFIDsignal 744 may be located within an integrated circuit that includesother functionality to protect the credentials. For example, theintegrated circuit may include a security module 746 that encrypts/signsthe credential (block 808) to prevent the information from being sentout of the integrated circuit in the clear. Here, the cryptographicprocessor in the security module 746 may use a private key to encryptthe information. A public key associated with this private key may bepublished with a certificate from a trusted entity. This certificateserves to verify that the public key is authentic. Cryptographicprocessing in the access device 702 may then use the public key toverify the signature of information received from the security module746.

A similar secure process may then be used to send the information to theaccess server 704. A complementary process may be used to securely sendinformation in the other direction across the link 726.

Accordingly, after the credential is signed by the cryptographicprocessor in the security module 708, the signed credential is sent tothe key manager 724 via the link 726 (block 810). In this way, theinformation is, in effect, sent over a secured channel (as representedby the corresponding portion of the line 718) even though the actualdata path may not be secure.

The key manager 724 sends the received information to the cryptographicprocessor 722 for decryption and/or authentication processing asnecessary. The key manager 724 then verifies that the receivedinformation indicates that the user is authorized to access the network(block 812). In some embodiments the access server 704 may include awireless proximity device (e.g., an RFID reader) and associatedprocessing to enable the credentials to be easily and directly loadedinto the access server when a user presents his or her token to theaccess server. In other embodiments the information may be acquiredusing a non-dedicated RFID reader. The acquired information may also beloaded into the access server by other means (e.g., downloaded via acommunication medium).

Since the key manager 724 has received an indication via thecryptographic signature associated with the credential that the token742 is proximate the access device 702, once the credentials areverified the key manager 724 may be assured that is safe to provideaccess to the requested service. As discussed above, providing access toa network may involve sending security associations or keys to theaccess device 702. These keys may be sent to the access device 702 viathe secured channel (cryptographic boundary 718). Accordingly, thecryptographic processor 722 may encrypt the keys before sending themover the link 726 (block 814).

The access device 702 may be configured so that these keys, etc., aredecrypted and maintained within the security boundary of the accessdevice 702 (block 816). For example, the keys may be stored within theintegrated circuit 712 (e.g., keys 740). Alternatively, a cryptographicprocessor in the security module may use a key (e.g., keys 740) toencrypt the received keys before storing them in the data memory 714.

As represented by block 818, the access device may then use the receivedkeys to gain access to the network as discussed herein. Again, in someembodiments these keys may only be used in the clear within the securityboundary of the access device 702.

Additional details of a proximity authentication device are disclosed,for example in commonly-owned U.S. patent application Ser. No.10/955,806, filed Sep. 30, 2004, the disclosure of which is herebyincorporated by reference herein.

FIG. 9 illustrates another embodiment of an access device that providesa secure mechanism for entering credentials. An access device 900includes a data interface 904 that is located within a security boundaryof the access device 900. For example, the data interface 904 may belocated on the same integrated circuit 902 as a security module 906. Asa result, credentials may be directly entered into the securityboundary.

In addition, the security module 906 may use one or more keys (e.g.,keys 908) to encrypt credentials within the security boundary so thatthe credentials are not provided in the clear outside of the securityboundary. Thus, the security module effectively extends the securityboundary using cryptographic techniques. For example, the securityboundary may be effectively extend (as represented by dashed lines 916)to an external data memory 914 by encrypting data before it is stored.In addition, the security boundary may effectively extend (asrepresented by dashed lines 920) through a communication medium toanother cryptographic processing system (not shown).

In the embodiment of FIG. 9, the access device incorporates a wirelessinterface 910 and an antenna 912 (or another form of a wirelesstransceiver) to communicate with other wireless devices (e.g., awireless access point and access server, not shown) via wireless signals918. In some embodiments the data communication interface 910 for theaccess device may advantageously be located on the same integratedcircuit as, for example, the security module 906. The wireless interfacemay support, for example, 802.11, Bluetooth and/or other wirelesscommunication standards.

In some embodiments the access device may forward the input informationto, for example, an access server to gain access to a service. Theinformation also may be enrolled with a key manager. Thus, as describedabove, the key manager may compare information received from an accessdevice with the key manager's database of authorized credentials (e.g.,fingerprint data). When a match is received, the key manager may providethe associated key(s) to the requesting access device.

In some embodiments the access server may include an input device andassociated processing to enable the information to be easily anddirectly loaded into the access server. In other embodiments theinformation may be acquired using a non-dedicated input device (e.g., asensor). The acquired information may then be loaded into the accessserver by other means (e.g., downloaded via a communication medium).

FIG. 10 illustrates one embodiment of a system 1000 that provides asecure mechanism for a user to enter credentials. A processing system1002 includes a secure processing system such as a trusted platformmodule (“TPM”) 1004.

Typically, the trusted platform module may generate and maintain keysfor the processing system. For example, a TPM may provide a set ofcryptographic capabilities that enable certain computer functions to besecurely executed within the TPM environment (e.g., hardware). To thisend the TPM may include one or more cryptographic processors thatperform cryptographic operations including, for example, encryption,decryption, authentication and key management. Specifications for a TPMare defined by the Trusted Computing Group organization.

Typically, to enable access to services managed by the TPM, a user mustfirst enroll his or her credentials with the TPM. This may involve, forexample, providing a password to the TPM. To this end, the TPM mayinclude an input device (not shown) that incorporates some of the secureinput mechanisms and techniques disclosed in the previous discussionsand the discussions that follow (e.g., direct connection, RFID,biometric sensor, keyboard, etc.).

Then, when a user wishes to access the services managed by the TPM, theuser must authenticate himself or herself to the TPM. This may involve,for example, providing the original password to the TPM. To this end,the processing system 1002 may include an input device 1006 that isconnected to the TPM via a link 1008.

In some embodiments, the link may be routed directly from the inputdevice to the TPM to ensure that data may be securely sent over thelink. For example, data from this link may not routed using softwareroutines such as operating system calls. In addition, data from the linkmay not be stored in data memory that is accessible by other componentsin the system. For example, the data may not be sent through a softwarestack and may not be stored in a data memory that is accessed via aninternal bus such as a PCI bus. Consequently, input information may bepassed to the TPM without being compromised by viruses, hackers, etc.,that may have compromised the system. In some embodiments an additionaldegree of protection may be provided by physically embedding orattaching the input device 1006 within/to the processing system.

Through the use of physical and cryptographic techniques the TPMsecurely uses and maintains sensitive information such as thesecredentials within its security boundary. After verifying thecredentials (e.g., comparing the received credentials with previouslyenrolled credentials) within the security boundary, the TPM 1004 mayprovide the requested access or may facilitate acquiring access to aservice from another processing entity.

In some embodiments a user may authenticate himself or herself to theTMP to use keys stored within the security boundary of the TPM. Forexample, the system of FIG. 10 may be used to access encrypted data(e.g., an encrypted password) stored in a local data memory (e.g., filestorage 1012). In this case, the TPM 1004 may store cryptographicinformation (e.g., keys, security associations, etc.) that enables theTPM to decrypt encrypted data. In a typical case, once the user isauthenticated, the TPM will use the key within its security boundary,then provide the results to the user. For example, the TPM may returndecrypted data (e.g., media content) or signed data to the user. In thisway, the keys may be used without exposing the keys in the clear outsidethe security boundary of the TPM.

In the event there is insufficient storage for the keys in the TPM, theTPM may encrypt the keys and send them to an external data storagecomponent (e.g., file storage 1012). Thus, even if the encrypted datafiles in the file storage 1012 may be accessed by other components inthe system the security of the encrypted data may be maintained becausethe keys are encrypted. In other words, sensitive information is onlyused in the clear within the security boundary of the TPM.

In some embodiments the TPM 1004 may control access to one or more datanetworks 1022 that are accessed via a network interface 1010. Here, theTPM 1002 may provide network authentication credentials (e.g., acertificate) to a service provider (e.g., an access point, not shown)connected to a network to authenticate it to the service provider. Thesenetwork authentication credentials may be securely stored in a datamemory (not shown) in the TPM 1004 or stored in encrypted form in thefile storage 1012.

The network interface 1010 may be used to connect to wired and/orwireless network(s). As discussed herein, cryptographic techniques maybe used to ensure the security of data transferred between the TPM 1004and other devices connected to the network. Accordingly, a networkconnection may be used, for example, to communicate with a key managerto obtain key information (e.g., security associations) andauthorization for key usage.

Input device 1014 depicts another embodiment of an input device that maybe used to securely provide information (e.g., credentials) to theprocessing system. The input device 1014 includes a security module 1018and keys 1020 implemented within a security boundary to providecryptographic functionality. For example, the security module may beused to encrypt/sign information (e.g., credentials) entered into theinput device. In this way, this information may be securely sent (asrepresented by dashed line 1016) to the TPM 1004.

The security module 1018 and the trusted platform module 1004 mayinclude components and perform operations as discussed herein to providestrong authentication and establish a secure channel. For example, apublic key and associated certificate may be published for the securitymodule 1018 to enable the TPM to verify the authenticity and thesecurity of the input device using techniques as discussed herein. As aresult, a secure channel 1016 may be established between thesecomponents such that the security boundary of the TPM may, in effect, beextended to include the input device 1014 and the secure channel.

Since information sent between the components may be secured in thismanner, the input device 1014 does not need to be securely connected tothe processing system. Thus, the input device 1014 may be advantageouslyused in applications where the input device is remote from theprocessing system 1002 and connected to the processing via, for example,a wired or wireless interface such as a network. In addition, the inputdevice may be advantageously used in applications where the input devicemay be connected to the TPM via an insecure link (e.g., a USB link in acomputer).

In some embodiments, the input mechanism (e.g., a key pad, a sensor,etc.) on the input device 1014 may be connected in a secure manner tothe security module 1018. For example, the input mechanism may belocated on the same integrated circuit as the security module. Inaddition, these components may be implemented within a physicallyprotected enclosure. Accordingly, the security boundary of the inputdevice 1014 may include the input mechanism, the security module 1018and external memory (not shown) that the security module uses to storeencrypted information. As a result, the input device 1014 may provide ahighly secure mechanism for a user to provide credentials to the TPM1004

Referring now to FIGS. 11-14 selected components and operations ofseveral embodiments of security modules will be discussed in moredetail. In some embodiments a security module may provide key protectionand management (e.g., enforcing proper usage of keys) required formultiple levels of key material.

In addition, a security module may provide cryptographic processing suchas encryption, decryption, authentication, verification and signing fora device that uses cryptographic services (e.g., an access device) inwhich the security module is installed. For example, a security modulemay be implemented in end-user client devices such as cell phones,laptops, etc., that need some form of data security, authentication,etc. In some embodiments the security module may be integrated intopreviously existing chips (e.g., a main processor) within these devices.

The security module may be configured as part of and to enforce asecurity boundary. For example, the security module may be configured tonever allow clear text keys to exit, for example, the security module orthe chip within which the security module is implemented. As a result,the security module may be safely integrated into other devices orsystems regardless of whether the system outside of the securityboundary is secure.

In this way, the security module may provide highly secure and costeffective remote key management for a client device. The security modulemay provide and/or support any required cryptographic processing. Asecurity boundary is established within the device to securely maintainand use keys and key material. Yet the system may be securely managed bya remote key management system (e.g., a hardware security module, a TPM,etc.) via the security module. Accordingly, a high level of securityfunctionality may be provided for the end-user device using a relativelysmall security module that has minimal impact on the rest of the device.

To support this key usage and management scheme, a security moduleprovides mechanisms for securely loading one or more keys into themodule, securely storing the keys and securely using the keys. Oneembodiment of a stateless hardware security module 1100 that providessuch mechanisms is depicted in FIG. 11.

The stateless module 1100 includes a master controller 1106 forcontrolling the overall operation of the module. For example, thecontroller may control boot operations, key management operations (ifapplicable) and data and key traffic flow into and out of the module.The controller may comprise, for example, a processor and associatedcode (e.g., ROM 1108) and/or a state machine or other hardware. Thecontroller and/or any other component in the stateless module maycommunicate with other components in the stateless module via aninternal bus 1130.

In some embodiments the master controller 1106 comprises a RISCprocessor with ROM code to execute the various commands necessary forthe operation of the stateless module. The master controller block alsomay include the address decoder for each of the slave blocks on theinternal bus 1130. The RISC engine may use a protected portion of a databuffer 1126 for temporary stack and scratch data space.

A bi-directional external interface 1120 provides a mechanism to sendkeys and/or data to or receive keys and/or data from the module. Forexample, the external interface may include registers that may bewritten to or read by the controller and external devices (e.g., a host)that are connected to the stateless module. In this case, the controllermay be configured so that it never writes certain data (e.g.,unencrypted keys) to the registers.

The external data interface 1120 may be used by a local host to readglobal registers, issue commands and place data into the data buffer1126 for processing by the stateless module. The external interface maybe controlled through a global register block 1122 by the mastercontroller. These global registers may include, for example, command(“CMD”), timer and configuration (“CONFIG.”) resisters. The mastercontroller transfers the data between the global registers block and adata buffer memory 1126.

The command interface provides a streaming data interface directly intothe data input and data output registers. It allows an external FIFO tobe used for data input and data output (separate FIFOs). This interfaceallows the stateless module to be easily embedded into a packet basedsystem.

In some embodiments, data (e.g., data to be processed or key material)to be encrypted or decrypted may be sent to or sent from the statelessmodule 1100 via one or more data interfaces. For example a datainterface 1102 may be used to send encrypted data or keys (e.g., thatwere decrypted by the module) to a cryptographic accelerator and viceversa. In addition, a data interface may be connected to an input device(e.g., a sensor) that generates data that needs to be encrypted by thestateless module. This encrypted data may then be sent to an externalprocessing component via the external interface 1120.

One or more cryptographic processing blocks perform any cryptographicprocessing that needs to be done to acquire or use keys or tocryptographically process data flowing though the module. For example,separate processing blocks may be used to perform asymmetric keyalgorithms such as DSA, RSA Diffie-Hellman (block 1114), key exchangeprotocols or symmetric key algorithms such as 3DES, AES (block 1112) orauthentication algorithms such as HMAC-SHA1 (block 1110). Thecryptographic processing block may be implemented, for example, inhardware and/or using a processor that executes code stored in a datamemory (e.g., ROM).

Typically this embodiment includes processing to generate asymmetrickeys that are used to establish a secure channel with a remote deviceand to authenticate information sent from the module to the remotedevice and vice versa. Here, the private portion of the asymmetric keymay be maintained within the security boundary of the chip. In addition,the stateless module also will include a mechanism for exporting thepublic version of the asymmetric key. For example, the public value maybe loaded into the external interface register discussed above so thatit may then be read by an external device. The public key value may beread from the stateless module by issuing a public key read command tothe stateless module. In response to this command the module returns thepublic key value and any non-secure configuration information for thedevice (authorization data, product configuration data, etc.).

In some embodiments a root, identity key serves as the basis for theasymmetric key. For example, the root key for the module may comprise anasymmetric key pair (secret or private, public) that is used to uniquelyidentify the stateless module. In some embodiments this key is only usedfor digital signatures to securely identify the stateless module.

In some embodiments, one or more keys (e.g., the root, identity key forthe module) may be injected into the stateless module. This may beperformed, for example, when the chip is manufactured, when the chip istested, during manufacture at an OEM (e.g., circuit board manufacturer),during OEM testing or during installation for the end user. Thistechnique may be used to inject symmetric and/or asymmetric keys.

In some embodiments, the stateless module may generate one or more keys(e.g., the root, identity key) internally. For example, the statelessmodule may include a random number generator (“RNG”) 1118 and othercircuitry necessary to generate a key. This embodiment may provide addedsecurity in that the generated key may never leave the security boundaryof the chip.

In some embodiments the device identity key comprises a collection ofrandom bits that are used to generate the key material for the long termfixed keys in the stateless module. For example, the RNG 1118 maygenerate a random number using the internal random number value as asecret initialization seed. The number of bits in the initializationseed may be determined by the amount of key entropy required for thesystem.

In some embodiments the value from the random number generator 1118 maynot be used directly. For example, it may be post processed using theSHA-1 block 1110 by the master controller before internal usage andbefore exposing the number external to the stateless module as a randomvalue. The master controller may maintain a cache of post processedrandom bits (for key generation and for signing) in the data buffer1126.

The random number generator 1118 may be a “true” random source. Forexample, it may utilize free running oscillators to capture thermalnoise as the source of randomness.

The stateless module also may include a privacy (or confidentiality)asymmetric key pair that may be used for transferring secure content tothe stateless module device via an intermediate insecure third partysuch that the third party does not have access to the key material. Insome embodiments the confidentiality key is only used to decrypt keymaterial within the stateless module.

The above keys (e.g., the root, identity key, etc.) may be stored in anonvolatile data memory (“NVM”) 1116. The NVM may comprise, for example,a one-time programmable (“OTP”) memory or battery backed memory (BBMEM)that is located on-chip or off-chip.

In some embodiments an on-chip OTP memory (as shown in FIG. 11) mayprovide certain advantages. For example, in this case the keys may bephysically protected within the device so that they cannot be easilyaltered or observed. In addition, since the use of the keys may beconfined within the chip, the keys may not appear in the clear outsideof the chip. Moreover, this OTP and stateless module combination maythen be implemented using a standard CMOS process. As a result, thestateless module may be readily integrated into a variety ofconventional chips that are used in end-user and other devices. Such acombination may provide a very cost effective security solution.

Examples of architectures and implementations of OTP memory that may beadvantageously implemented in CMOS are described in, for example, U.S.Pat. Nos. 6,525,955, 6,693,819, 6,700,176 and 6,704,236 and U.S. patentapplication Ser. No. 09/739,952, filed Dec. 20, 2000, the disclosure ofeach of which is hereby incorporated by reference herein.

The OTP may be programmed by the master controller 1106 via aprogramming interface in conjunction with an external programming signalVPP. The master controller may ensure (via local hardware enforcement)that the device keys, authorization and configuration data can beprogrammed once and only once.

The key-encryption-key (“KEK”) cache 1124 is a separate memory blocksized based on the required number of KEKs in the system. Typically, itis large enough to hold the session private key and a single asymmetricgroup key.

The KEK Cache 1124 may be protected in hardware during the execution ofany command that does not require a KEK key. For example, a signal fromthe global registers may be provided to the KEK cache to indicate thatthe command register is locked, active and contains a command thatrequires a KEK. Some KEK cache locations are contained in the NVM blockthat is used to implement the long term keys for the stateless module.

The application key cache 1104 may be used by the master controller toprovide encryption and decryption storage for the internal accelerationcores (such as the public key core 1114 or the 3DES core 1112). Theapplication key cache may enforce key lifetime expiration when the keysare used by either the stateless module commands or the application keycache interface.

In general, the performance, size and function of the blocks discussedabove may be scaled to meet the demands of the system. For example, thebasic cryptographic functions that implement the secure channel back tothe key manager to transfer and process key material (and/or policy) maybe provided at minimal processing performance levels.

The cryptographic accelerators contained within the stateless module canbe used for application data processing when they are not being used forkey management functions. For example, a stateless module for ane-commerce application may be used to protect RSA private keys. Here,the public key acceleration required for the secure channel is typicallyminimal (less than 10 operations/sec). Consequently, any spareprocessing capacity (e.g., idle cycles of a processor) may be used forother operations.

In contrast, public key acceleration required for a typical e-commerceaccelerator is relatively high (greater than 500 operations/sec).Applications such as this may require the use of cryptographicaccelerators that are specially designed to perform cryptographicoperations at a high rate of speed.

One or more cryptographic accelerators may be attached directly to thestateless module via the application key cache interface 1102.Typically, the application key cache interface for the add-oncryptographic acceleration processing is maintained within the securityboundary. For example, the stateless module and the cryptographicaccelerators may be implemented on the same chip. In this manner, thecleartext keys are not allowed to leave the security boundary which alsoincludes the public key accelerator. However, the external applicationmay use the public key accelerator as it normally would by simplyreferencing the appropriate RSA private key stored in the statelessmodule.

The application key cache 1104 also may store key material that may beused by external cryptographic acceleration processors. For example, thecache 1104 may store decrypted application keys (e.g., the RSA privatekey for an application executing on the device that contains thestateless module).

The stateless module enforces key policy for keys used within the remoteclient. The key policy may be set by the key manager for all keys thatare delivered to the stateless module. The key policy indicates how thekey can be used by the stateless module. In addition to usage policy,the stateless module can enforce a lifetime for keys. Typically, a keylifetime is a relative time from the time at which the key is loadedinto the stateless module. The key manager can use the multiple levelsof key hierarchy and the lifetime policy enforcement to ensure that keysare used properly and are revocable at the stateless module.

A security assurance logic block 1128 protects the stateless module fromsystem security attacks. To this end, several system monitors may becoupled with the other components in the stateless module and/or thechip (and/or the system) within which the stateless module resides.

In some embodiments, the protection circuits trigger a reset of thestateless module when an attack is detected. This reset may wipe out alltransient information in the stateless module. For example, all keycache locations may be cleared. An interrupt may be provided to thelocal host with information on which protection mechanism triggered thereset.

A low frequency protection circuit ensures that the operating frequencyof the stateless module does not fall below given threshold. Thisensures that the time tick register value can not be compromised withinthe limit of a reference frequency. In addition to protecting the timetick value, the low frequency protection circuit makes it more difficultto implement successful dynamic attacks that attempt to read valueswithin the stateless module while it is operating. In this case, thehigher the threshold value, the better protection that is provided.

An operating point protection circuit may be provided to ensure that alllogic within the stateless module operates as designed for all process,voltage and temperature conditions (or across all operating points). Theprotection circuit helps ensure that an attacker cannot change theoperating point such that a timing path is violated in the statelessmodule.

A watchdog timer block may be used during processing to ensure thatcommand execution completes within an expected period of time. The timeris set by the master controller whenever a command (or sub-command suchas a public key operation) is started. The set time is based on theexpected maximum command length. If the watchdog timer reaches zero areset is issued to the stateless module. The watchdog timer cannot beturned off and must be written periodically by the master controller toavoid clearing the stateless module. The watchdog timer may be frozenwhen the stateless module is taking command input from the host.

A reset monitor provides protection against multiple reset attacks. Thereset monitor uses a timer based on the time tick register incrementthat requires at least one tick before allowing more than, for example,sixteen resets to occur. If more than sixteen resets occur within thetime tick, the stateless module will require at least two time ticksbefore releasing the sixteenth reset. The reset protection is disableduntil the NVM has been properly programmed. For example, it may bedisabled during manufacturing tests.

A hardware protection mechanism may be provided for entering and exitinga secure state while the stateless module transitions betweenenabling/disabling the external interface. The stateless module boots toa secure state with the external interface disabled. That is, theinterface is locked out by hardware. Once reset processing andself-tests have completed, the master controller sequences through aseries of commands to exit the secure state and enter a USER state. Insome embodiments these commands require execution of a predefined set ofsequential instructions be written to non-sequential addresses.

The hardware tracks the number of clocks it takes to execute each stepof the sequence and ensures that these commands occur in the requiredorder to the required address at exactly the right clock cycle. Afterthe exit logic has completed, the mode is set via hardware to USER mode.In USER mode, the hardware locks out master controller access to all ofthe internal blocks except the data buffer and the data input/outputregisters (only blocks that are required to move data into the device).

Once the command has been moved into the data buffer, the mastercontroller sequences a series of commands to return to the secure state.This sequence is again tracked and enforced via the hardware block toenter into secure mode. It also ensures via hardware that the mastercontroller enters the secure mode with the proper entry address.

The master controller ROM 1108 may be programmed using an extra bit toindicate which instructions are valid code entry and code exit points.The instruction code entry/exit points are enforced in hardware wheneverthe master controller takes a non-sequential code fetch. This mechanismhelps to ensure that it will be difficult for an attacker to get themaster controller to bypass certain portions of code. As a result, itmay be virtually impossible to successfully attack the module by causingrandom jumps in the program execution.

To reduce cost and die space, the stateless module may not handleprocessing related to communication protocols. Instead, the requirementsof communication protocols may be handled by an associated device driver(or integrated processor).

In an alternative embodiment, the stateless module may be assignedlong-term keys. In this case, the stateless module may not need tointerface with a head-end server (e.g., key manager).

Referring now to FIG. 12, an example of operations that may be performedby one embodiment of a stateless module will be discussed. Asrepresented by block 1202, when the stateless module is initialized forthe first time after manufacture (e.g., during final test of the chip),the master controller may cause the random number generator 1118 togenerate a random number that is provided as a seed to a cryptographicprocessor that generates a public-private key pair.

The master controller stores the private (identity) key in thenonvolatile memory 1116 and never exports this key outside of thesecurity boundary of the module (block 1204). For example, in someembodiments the key never leaves the chip within which the statelessmodule resides. In some embodiments this key is encrypted before beingstored in off-chip non-volatile memory.

The stateless module also stores the corresponding public key and, uponrequest, exports the public key (block 1206) so that the devicemanufacturer (or some other trusted entity) may publish the public keyalong with a certificate to a public server.

The stateless module may then be deployed in a computing device that canconnect to another device (e.g., a key manager) via a network or someother link. As represented by block 1208, the stateless module may useits private key to establish a secure communication channel with, forexample, a security module (e.g., a key manager) that has access to thestateless module's public key.

As represented by block 1210 the key manager may send keys to thestateless module via the secure communication channel. For example, thekey manager and stateless module may negotiate to obtain additional keysthat may be used to provide secure communications between the twocomponents. In addition, the key manager may send keys to a remoteclient via the stateless module. For example, the key manager maygenerate a private session key (Ka-priv) for a client that incorporatesthe stateless module. As discussed above, the key manager may encryptthis key using the stateless module's public key (Kdc-pub) or somenegotiated key before sending it to the client.

As represented by block 1212, the keys are decrypted within the securityboundary associated with the stateless module. For example,cryptographic processors in the stateless module may decrypt these keys.Alternatively, another cryptographic processor located on the same chipas he stateless module may decrypt the keys.

As represented by block 1214, the stateless module may then use the keyswithin the security boundary. For example, cryptographic processors inthe stateless module may use these keys to decrypt other keys (e.g.,session keys). In addition, the stateless module may enforce key policywithin the security boundary (block 1216).

In some embodiments, as represented by block 1218, the stateless modulemay provide keys to one or more cryptographic accelerators within thesecurity boundary. For example, the cryptographic accelerators may belocated on the same chip as the stateless module.

Referring now to FIG. 13, one embodiment of a stateless secure linkmodule 1300 will be discussed in detail. This embodiment includes, ingeneral, a subset of the functionality of the embodiment of FIG. 11. Inparticular, this embodiment only provides data encryption, decryption,etc. using a symmetric key. One advantage of this configuration is thatit may be implemented in other devices with even less impact on the costand the size of the devices.

In a typical application the embodiment of FIG. 13 is used to take datathat originates from an input device and securely provide that data to arecipient device that uses the data (e.g., an access device or an accessserver). This process may involve encrypting the data so it does notappear in clear text and/or signing the data to certify to the recipientdevice that the data originated from a specific input device.

For example, the stateless module may be integrated into a chip for asensor (e.g., a biometric sensor such as a fingerprint reader). Here,the stateless module may be used to sign and/or encrypt the informationgenerated by the sensor. The stateless module may then securely send theinformation to a recipient device that uses the information. In thiscase, the recipient device may use a fingerprint comparison as a meansto control access to data or a service.

In some embodiments the sensor data is always maintained within asecurity boundary. First, by incorporating the stateless module into thesensor chip, the information may be encrypted before it leaves thehardware boundary of the chip. Second, the stateless module mayestablish a secure channel with the recipient device through a symmetrickey exchange. In this way, the information may be securely sent to therecipient device. Third, the recipient device may be secured in aconventional manner or using techniques as described herein.

As an example of the latter scenario, the recipient device may include astateless module as described above in conjunction with FIG. 11. In thiscase, the recipient device may use other keys to, for example, securelysend the information to a remote system. One example of such a remotesystem is a network access device that enables access to a network basedon the user's credentials such as the user's fingerprint.

In other embodiments, it may only be necessary to establish that thedata originated from a specific input device. For example, the systemmay make other provisions to ensure that a copied fingerprint datastream is not being replayed at a later time. In this case, it may beunnecessary to encrypt the information. All that may be needed here isan assurance that the information is being sent by a specific sensor. Inthis case, adequate security may be provided by simply signing the data.

To provide a solution that is cost effective for a variety of inputdevices, the stateless module of FIG. 13 has a reduced set offunctionality as compared to, for example, the embodiment of FIG. 11.The stateless module includes a master controller 1306 and an externalinterface 1312 to enable the asymmetric key operations that areperformed when the secure link is initially established with, forexample, a key manager. Thus, the controller 1306 includes circuitry togenerate and verify the validity of its keys. In addition, the modulemay include assurance logic 1320 similar to that discussed above.

However, because the module only uses a single symmetric key, much ofthe functionality depicted in FIG. 11 is not provided in the embodimentof FIG. 13. For example, the module does not need to provide managementcapabilities (e.g., enforcement of key policy) and data storage (e.g.,application key cache) for extra keys. Also, the non-volatile ROM(“NVROM”) 1310 may be smaller since it may only store, for example, anidentity key and a symmetric key.

Moreover, as this module only performs symmetric cryptographicprocessing on data from a data streaming interface, some or all of thededicated cryptographic processors shown in FIG. 11 (e.g., the publickey processing and 3DES) may not be needed. For example, the module onlyperforms the asymmetric key operations once after it boots up. Inaddition, the stateless module does not need to verify the authenticityof the recipient of the data. Accordingly, the remaining cryptographicprocessing operations may be performed by the master controller 1306. Inthis case, the application code for cryptographic algorithms (e.g., DH,DSA, 3DES, AES) may be stored in a ROM 1308.

The embodiment shown in FIG. 13 may secure an incoming data stream (DI)by signing it using the SHA-1 algorithm. Accordingly, a separateprocessing block 1304 may be provided for this operation. The signedoutput of this processing 30 block provides a data stream (DO) that issent to the recipient device via a data interface 1302. In an embodimentthat also encrypts the data stream, a dedicated processing block (notshown) may be provided to implement, for example, a symmetric encryptionalgorithm.

Referring now to FIG. 14, an example of operations that may be performedby one embodiment of a stateless secure link module will be discussed.As represented by blocks 1402-1408, a stateless secure link modulegenerates a public-private key pair, stores the private (e.g., identity)key in nonvolatile memory within the security boundary, exports thepublic key and establishes a secure communication channel with, forexample, a key manager.

As represented by block 1410 the key manager may send symmetric keys tothe stateless secure link module via the secure communication channel.For example, the key manager may send symmetric keys that are used toencrypt and/or sign data that the stateless secure link module receivesfrom an input device. The cryptographic processors may then decryptthese keys (block 1412) and store the decrypted keys (block 1414) withinthe security boundary associated with the stateless secure link module.

As represented by block 1416, the stateless module may receive data tobe encrypted from an input component. As discussed above the inputcomponent may be, for example, a biometric sensor, a sensor for acamera, etc., or any other device that needs data to be authenticated orsecurely transmitted to another (e.g., remote) device (e.g., therecipient device).

As represented by blocks 1418, the stateless module uses the symmetrickeys within the security boundary to encrypt the data. Then, asrepresented by block 1420, the stateless module sends the encrypted datato the remote device.

In some embodiments the symmetric key may be injected into the statelessmodule during manufacture (e.g., during chip test). In this case, all ora portion of the external interface 1312, the RNG 1316 and theasymmetric key processing circuitry may not be needed. Accordingly, insome embodiments a stateless module may simply include a relativelysmall master controller for injecting the symmetric key and performother basic operations, a nonvolatile memory, a data buffer memory, acryptographic processor for the symmetric key operations and optionally,assurance logic.

Additional details of security modules are disclosed, for example, incommonly-owned U.S. patent application Ser. No. 10/______ , filed Jun.21, 2005, entitled STATELESS HARDWARE SECURITY MODULE, Attorney DocketNo. 53028/SDB/B600, the disclosure of which is hereby incorporated byreference herein.

It should be appreciated that the various components and featuresdescribed herein may be incorporated in a system independently of theother components and features. For example, a system incorporating theteachings herein may include various combinations of these componentsand features. Thus, not all of the components and features describedherein may be employed in every such system.

Different embodiments of the invention may include a variety of hardwareand software processing components. In some embodiments of theinvention, hardware components such as controllers, state machinesand/or logic are used in a system constructed in accordance with theinvention. In some embodiments code such as software or firmwareexecuting on one or more processing devices may be used to implement oneor more of the described operations.

Such components may be implemented on one or more integrated circuits.For example, in some embodiments several of these components may becombined within a single integrated circuit. In some embodiments some ofthe components may be implemented as a single integrated circuit. Insome embodiments some components may be implemented as severalintegrated circuits.

The components and functions described herein may be connected/coupledin many different ways. The manner in which this is done may depend, inpart, on whether the components are separated from the other components.In some embodiments some of the connections represented by the leadlines in the drawings may be in an integrated circuit, on a circuitboard and/or over a backplane to other circuit boards. In someembodiments some of the connections represented by the lead lines in thedrawings may comprise a data network, for example, a local networkand/or a wide area network (e.g., the Internet).

The signals discussed herein may take several forms. For example, insome embodiments a signal may be an electrical signal transmitted over awire, light pulses transmitted through air or over an optical fiber orelectromagnetic (e.g., RF or infrared) radiation transmitter transmittedthrough the air.

A signal may comprise more than one signal. For example, a signal mayconsist of a series of signals. Also, a differential signal comprisestwo complementary signals or some other combination of signals. Inaddition, a group of signals may be collectively referred to herein as asignal.

Signals as discussed herein also may take the form of data. For example,in some embodiments an application program may send a signal to anotherapplication program. Such a signal may be stored in a data memory.

The components and functions described herein may be connected/coupleddirectly or indirectly. Thus, in some embodiments there may or may notbe intervening devices (e.g., buffers) between connected/coupledcomponents.

A wide variety of devices may be used to implement the data memoriesdiscussed herein. For example, a data memory may comprise flash memory,one-time-programmable (OTP) memory or other types of data storagedevices.

In summary, the invention described herein generally relates to animproved authentication system and method. While certain exemplaryembodiments have been described above in detail and shown in theaccompanying drawings, it is to be understood that such embodiments aremerely illustrative of and not restrictive of the broad invention. Inparticular, it should be recognized that the teachings of the inventionapply to a wide variety of systems and processes. It will thus berecognized that various modifications may be made to the illustrated andother embodiments of the invention described above, without departingfrom the broad inventive scope thereof. In view of the above it will beunderstood that the invention is not limited to the particularembodiments or arrangements disclosed, but is rather intended to coverany changes, adaptations or modifications which are within the scope andspirit of the invention as defined by the appended claims.

1. An authentication method comprising: receiving authentication data atan input device; cryptographically processing the authentication data atthe input device; transmitting the cryptographically processedauthentication data to an access device; processing the transmittedauthentication data at the access device; transmitting the processedauthentication data to a service provider.
 2. The method of claim 1wherein cryptographically processing includes at least one ofauthenticating and encrypting.
 3. The method of claim 1 whereincryptographically processing comprises using a symmetric key provided bythe access device.
 4. The method of claim 1 wherein cryptographicallyprocessing comprises using a symmetric key injected into the inputdevice during manufacture of the input device.
 5. The method of claim 1comprising establishing cryptographic link between the input device andthe access device.
 6. The method of claim 1 comprising performingasymmetric key operations between the input device and the accessdevice.
 7. The method of claim 1 comprising generating an asymmetric keypair within the input device.
 8. The method of claim 1 comprisinggenerating an asymmetric key pair within a security boundary of theinput device.
 9. The method of claim 1 wherein the authentication datais received within a security boundary of the input device.
 10. Themethod of claim 1 wherein the input device comprises a sensor.
 11. Themethod of claim 1 wherein the input device comprises a proximityauthentication system.
 12. The method of claim 1 wherein processing thetransmitted authentication data comprising authenticating thetransmitted authentication data.
 13. The method of claim 1 wherein theservice provider grants access to at least one service in response tothe transmitted processed authentication data.
 14. The method of claim 1wherein the service provider enables access to a network in response tothe transmitted processed authentication data.
 15. A secure dataprocessing system comprising: an input device adapted to receiveauthentication data, cryptographically process the authentication dataand transmit the cryptographically processed authentication data over amedium; and an access device adapted to receive the transmittedauthentication data, process the received authentication data andtransmit the processed authentication data to a service provider. 16.The system of claim 15 wherein cryptographically process includes atleast one of authenticating and encrypting.
 17. The system of claim 15wherein cryptographically process comprises using a symmetric keyprovided by the access device.
 18. The system of claim 15 whereincryptographically process comprises using a symmetric key injected intothe input device during manufacture of the input device.
 19. The systemof claim 15 wherein the input device and the access device are adaptedto establish a cryptographic link between the input device and theaccess device.
 20. The system of claim 15 wherein the input device andthe access device are adapted to perform asymmetric key operationsbetween the input device and the access device.
 21. The system of claim15 wherein the input device is adapted to generate an asymmetric keypair.
 22. The system of claim 15 wherein the input device is adapted togenerate an asymmetric key pair within a security boundary of the inputdevice.
 23. The system of claim 15 wherein the authentication data isreceived within a security boundary of the input device.
 24. The systemof claim 15 wherein the input device comprises a sensor.
 25. The systemof claim 15 wherein the input device comprises a proximityauthentication system.
 26. The system of claim 15 wherein processing thetransmitted authentication data comprising authenticating thetransmitted authentication data.
 27. The system of claim 15 wherein theservice provider grants access to at least one service in response tothe transmitted processed authentication data.
 28. The system of claim15 wherein the service provider enables access to a network in responseto the transmitted processed authentication data.